fix(core): ValueDataSource's contains is case-sensitive and icontains is its ASCII-folding twin - #8437

Fixes #7379

The escalation fence resolves to DEFECT, and here is the measurement that decides it

The card's fence: if the spec keeps contains and icontains deliberately distinct and ValueDataSource is the odd one out among the drivers, it is a defect; if it is the only driver, or the drivers disagree, it is a product ruling. It is the first. The sibling drivers' behaviour, not the spec text:

The canonical rows those eight faces answer are FILTER_TEXT_CASES in @objectstack/spec/data, whose $contains is case-SENSITIVE case reads: { name: { $contains: 'acme' } } over ACME Corp / acme corp selects row 2 only. So the disagreement is with the other implementations, not with a document.

Two things I measured rather than assumed, both by executing the installed @objectstack/spec 17.3.0:

• asciiCaseInsensitiveContains('CAFÉ', 'café') is false, while 'CAFÉ'.toLowerCase().includes('café') is true. The fold is ASCII-only by ruling (objectstack#4706 Q1 = A) because three of five backends are SQLite underneath and its lower() folds ASCII only.
• No i twin exists for the other three operators. VALID_AST_OPERATORS.has(...) answered: icontains true; istartswith, iendswith, noticontains, not_icontains all false. The triage seat asked for exactly this and told me not to assume duals — there are none, so case-sensitive is the only reading starts_with / ends_with / not_contains have.

What changed

Five arms in packages/core/src/adapters/ValueDataSource.ts, all of which lower-cased both sides:

1. contains, not_contains, starts_with, ends_with compare exactly. Judged as one group per the triage seat's boundary — a case-exact contains beside a folding not_contains lets ACME Corp fail an operator and its negation.
2. icontains gets its own arm and takes the spec's exported asciiCaseInsensitiveContains. Before this it shared the contains body, so PR fix(core): teach ValueDataSource's matcher the filter vocabulary the wire already has #7377's mapping made the two identical; now it is the one case-insensitive member, folding ASCII on both sides.
3. The $-dialect matcher (matchesFilter) follows: $contains compares exactly, and $icontains gains an arm. It had none — an unrecognised $ operator in that switch reaches default: break, which adds no constraint, so { name: { $icontains: 'acme' } } used to select every row. Making $contains exact without adding its twin would have left that dialect with no working case-insensitive door.

The direction is written at the arm (the card's third acceptance criterion), naming the ruling and the drivers, so the next reader does not take it for a typo.

Deliberately not touched: canonicalAstOperator (#7349 / PR #7377's work, and correct), and the $search path's toLowerCase() — full-text search is case-insensitive by ruling (objectstack#7641), a different question from a filter operator.

The pin

packages/core/src/adapters/__tests__/ValueDataSource.textOperatorCase.test.ts, 14 cases. Every assertion is a row-set equality, never an operator-name check: a matcher that returns every row constructs exactly the right operator string.

Both halves over one fixture (ACME Corp / acme corp / CAFÉ / café):

• EXCLUSION — ['name','contains','acme'] selects ['lower']; ACME Corp must not come back.
• INCLUSION — ['name','icontains','acme'] over the same fixture selects ['upper','lower'], i.e. the row contains just dropped.

Would an implementation strictly worse than the bug pass it? No, and that is its own named case — a matcher answering [] for everything FAILS these cases, not just passes the exclusions. Ablation leg 2 below proves it fires.

Ablation — two legs, both from the committed implementation

Leg 1 — restore the case-fold at the contains READ SITE. On-disk proof: HEAD:...ValueDataSource.ts blob 2722d1ba8dff3cc8b5d7defe81b2c556b86c93ca, mutated on-disk git hash-object 2a25e57da0dd179b64430a25cdf5258c58b892f6 — different, so the mutation reached disk. Result 5 failed | 9 passed, red by name:

× a lower-case comparand: `contains` misses the upper-case row, `icontains` takes both
    -> `contains` is case-SENSITIVE — ACME Corp must NOT come back:
       expected [ 'upper', 'lower' ] to deeply equal [ 'lower' ]
× an upper-case comparand: the mirror, so neither direction is a lucky count
× the two operators cannot silently re-converge: they disagree on this fixture
× `not_contains` is case-sensitive, and complements `contains` exactly
× both dialects answer the same rows for the same question

Leg 2 — the strictly-worse implementation: both dialects' icontains answer nothing. Blob 2722d1ba… vs mutated 4a0f83a7acf71bf175580839f56492007adaa149. Result 6 failed | 8 passed, headed by:

× a matcher answering [] for everything FAILS these cases, not just passes the exclusions
× a lower-case comparand: `contains` misses the upper-case row, `icontains` takes both
× É does not fold to é, in either direction
× $contains excludes the case-differing row and $icontains includes it

Both legs restored by state, not by exit code: git diff HEAD empty, git status --short empty, and on-disk git hash-object back to 2722d1ba…. The pin re-ran 14 passed (14) afterwards. No rebuild step is involved: the pin imports ../ValueDataSource (relative source), so there is no dist/ hop that could stale the reading.

Verification, on the final commit c889b18a7

• pnpm exec vitest run packages/core/ plus the 67 other test files that reach a value-provider datasource: Test Files 190 passed (190) · Tests 3364 passed (3364).
• That 67-file set is a measured narrowing, not a guess: the change is confined to two functions in ValueDataSource, so a test can only observe it by (a) reaching that adapter and (b) passing one of the six operator spellings. The union above is condition (a) over the whole repo — 76 files across 12 packages, every one run. turbo ls --affected names 38 packages because @object-ui/core is a base dependency; those are declared to CI's four shards.
• pnpm --filter @object-ui/core type-check (tsc --noEmit && tsc -p tsconfig.test.json): exit 0. The new file is in the program — tsc -p tsconfig.test.json --listFiles lists it (1 hit), lit control adapters/ValueDataSource.ts 1 hit, negative control 0 hits.
• eslint . in packages/core: 518 problems (0 errors, 518 warnings), all pre-existing no-explicit-any.
• node scripts/check-changeset-presence.mjs: ✅ 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s): .changeset/wise-poems-behave.md.
• node scripts/check-changeset-no-major.mjs: ✅ No changeset declares a 'major' bump.
• Control-character self-scan over the three touched source files: zero hits.

Changeset level: minor

Scored minor because this moves shipped results — metadata relying on the lenient matching gets fewer rows and no error — and the repo forbids major (every package is in one fixed group, so one major carries all of them off the pinned @objectstack major; check-changeset-no-major.mjs enforces it). patch would be wrong: this is not a fix that leaves behaviour where it was. The changeset body names the migration explicitly — a filter that means "match regardless of case" is authored as icontains or $icontains, and both now execute.

Dependency range: checked, no bump needed

packages/core declares "@objectstack/spec": "^17.2.0". asciiCaseInsensitiveContains is present in 17.2.0's published api-surface/data.json and its dist/data/index.d.ts (read from the 17.2.0 tarball; positive control canonicalAstOperator present, negative control absent). So the declared range is honest and stays.

Two out-of-scope findings, both MEASURED, neither fixed here

Reported for filing — search_issues returned API rate limit already exceeded for user ID 323634890 on both dedupe queries, and repo-scoped REST is 403 for this seat, so I could not search and therefore did not file.

A. matchesFilter waves through every $ operator it does not recognise. Same defect class as objectui#7349, in the dialect #7349 did not touch. Measured over rows n (score: 5) and s (score: '5'):

{ score: { $nin: [5,'5'] } }      -> ['n','s']   (must be [])
{ score: { $startsWith: 'zzz' } } -> ['n','s']   (must be [])
{ score: { $null: true } }        -> ['n','s']   (neither row is null)
{ score: { $exists: false } }     -> ['n','s']

The implemented set is $gt $gte $lt $lte $ne $in $contains plus the $icontains this PR adds; everything else is silently no-constraint. Not fixed here: closing it means refusing unknown operators the way matchesASTFilter does, which moves results for every one of those spellings — its own card, its own escalation.

B. not_contains answers NO for a stored value that is not a string, so a row fails the operator AND its negation. Measured: ['score','contains','5'] selects ['s'] (correct — a number cannot contain a substring) but ['score','not_contains','5'] selects [], dropping row n from the negation too. The platform ruled this cell on 2026-09-05 (objectstack#14079, option A): a non-string never satisfies a positive text operator and does satisfy $notContains. FILTER_TEXT_CASES pins it on every face; ValueDataSource has exactly the shape the reference matcher had before that card. Different axis from this one (stored-value type, not case folding), so it is not ridden in here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YBWFb5YgMU5dw8p2VKj16S

Generated by Claude Code